Systems and methods for capturing real time client side data and for generating a permanent record

ABSTRACT

A system is provided for generating a permanent record for an, e.g., online transaction. The system includes a computer interface module which records movement of a cursor on a computer screen and outputs the recorded data. A signature generation module which receives the recorded data and generates a graphical image based upon the recorded data. A webpage reading module reads the webpage and the data input by a user and outputs the combined content and data to a rendering process, which renders a permanent computer record file that includes an image capture of the transaction (content and data) along with, optionally, the signature. According to the present invention, a record can be created that includes the exact content and other information presented to a party to an online transaction along with a signature of that party.

PRIORITY CLAIMS

This application is a continuation of U.S. patent application Ser. No.16/218,265 filed on Dec. 12, 2018, which is a continuation of U.S.patent application Ser. No. 15/599,287, filed on May 18, 2017, which isa continuation of U.S. patent application Ser. No. 13/605,095, filed onSep. 6, 2012, which claims priority to U.S. Provisional Application No.61/635,014 filed on Apr. 18, 2012, the entire contents of which ishereby incorporated by reference. This application is also aContinuation-In-Part application of and claims priority to U.S.application Ser. No. 13/073,819, filed on Mar. 28, 2011, now U.S. Pat.No. 8,588,483, which is a Continuation of and claims priority to U.S.application Ser. No. 11/312,397, filed on Dec. 21, 2005, now U.S. Pat.No. 7,916,906, which is a Continuation-In-Part application of and claimspriority to U.S. application Ser. No. 11/205,002 filed on Aug. 17, 2005,and claims priority to U.S. Provisional Application No. 60/593,210 filedon Dec. 21, 2004; the entire contents of each of which are herebyincorporated by reference.

BACKGROUND OF THE INVENTION Field of the Invention

The present invention relates generally to systems and methods forcapturing real-time client-side data. Other aspects of the inventionrelate to merging the captured data with an online biometric signature.Other aspects of the invention relate to generating a permanent recordbased on the captured data and/or the online biometric signature.

Description of the Related Art

Since the outset of the Internet, electronic commerce has proliferateddramatically. It is now common place to transact all types business overthe Internet. Retail sales have benefited from the Internet, and nowmost merchants have web sites that allow online purchasing via a websiteor online catalogue. All that is needed to complete a purchase is accessto the Internet and a credit card.

Online merchants are handicapped by the lack of a written contractsigned by its customers. If an online purchaser disputes a credit cardtransaction, the merchant will not have a signed contract to prove thelegitimacy of the transaction. As a result, online vendors are exposedto undue risk.

Further, customers entered valuable information in connection withonline transactions that is difficult to capture due to the nature ofexisting e-commerce solutions. Such client-side data is useful forproving the terms and conditions of the corresponding onlinetransaction.

There is a need for systems and methods for client-side data inconnection with online transactions and for generating permanent recordsbased on the captured information. Such permanent records can be moreuseful if the generated record also includes a captured customersignature along with the terms and conditions associated with thecorresponding online transaction.

SUMMARY OF THE INVENTION

According to an embodiment of the present invention, a system isprovided for generating a permanent record for an, e.g., onlinetransaction. The system may include a signature module, a screen scrapemodule, and a rendering module. The signature module includes a computerinterface module which records movement of a cursor on a computer screenand outputs the recorded data; and a signature generation module whichreceives the recorded data and generates a graphical image based uponthe recorded data. The screen scrape module reads the webpage and thedata input by a user and outputs the combined content and data to therendering module, which renders a permanent computer record file thatincludes an image capture of the transaction (content and data) alongwith, optionally, the signature. Therefore, a record can be created thatincludes the exact content and other information presented to a party toan online transaction along with a signature of that party.

The screen scrape module is preferably configured to “walk” the DOM ofan HTML page and to insert into the HTML the data that has been input bythe user to therefore, output a combination of the actual content anddata that is part of the user experience.

The rendering process preferably generates a non-editable file, such as,e.g., PDF.

According to aspects of the present invention, the screen scrape modulemay be stand alone.

According to aspects of the present invention, the screen scrape andrendering modules may be combined to form a stand-alone application.

According to aspects of the present invention, remote storage andsecurity can be provided so as to securely record online transactionused for validation of the corresponding transaction.

Further applications and advantages of various embodiments of thepresent invention are discussed below with reference to the drawingfigures.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is view of a signature block according to an embodiment of thepresent invention.

FIG. 2 is a view of a signature block including an email address formfield, according to another embodiment of the present invention.

FIG. 3 is a view of a signature block including additional form fieldsaccording to another embodiment of the present invention.

FIG. 4 is a block diagram of a system for capturing a real-time onlineelectronic, biometrically accurate signature according to an embodimentof the present invention.

FIG. 5 is a screen shot of a signature image generated according to anembodiment of the present invention.

FIG. 6 is a flow chart of a real-time online electronic, biometricallyaccurate signature capture process according to an embodiment of thepresent invention.

FIG. 7 is a view of a signature block including additional form fieldsaccording to another embodiment of the present invention.

FIG. 8 is a block diagram of a system for capturing client-side dataaccording to an embodiment of the present invention.

FIG. 9 is a flow chart that illustrates steps of a method for capturingclient-side data according to an embodiment of the present invention.

FIGS. 10A and 10B are data process flow diagrams of an onlinetransaction according to an embodiment of the present invention.

FIGS. 11A and 11B are data process flow diagrams for generation of apermanent record associated with an online transaction according to anembodiment of the present invention.

FIGS. 12A and 12B are data process flow diagrams of a rendering processfor generation of a permanent record associated with an onlinetransaction according to an embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

While the present invention may be embodied in many different forms, anumber of illustrative embodiments are described herein with theunderstanding that the present disclosure is to be considered asproviding examples of the principles of the invention and such examplesare not intended to limit the invention to preferred embodimentsdescribed herein and/or illustrated herein.

SIGNATURE LINK®, invented a program, application, module, component orthe like that displays a signature pad on a computer screen (e.g.,within a web browser window) and captures signatures input via a mouseor other peripheral device (e.g., writing pad, keyboard arrows, touchpad, etc.). The signature pad can be a stand-alone Macromedia Flashprogram, but could be programmed in other languages such as, but notlimited to, JavaScript, ActiveX, MS Sparkle, MS .Net, MS Longhorn,Vista, etc. The signature pad may be executed by a hosting application(e.g., web browser) or the like and can be called from any application,such as from an HTML, XML, or XAML page, or may be a browser plug-in.Features of the signature pad are described in co-owned U.S. Pat. No.7,916,906 which has already been incorporated herein by reference.

Preferably, the signature pad is configured to capture a raw signature(i.e., biometric signature) and generate a graphical image thereof. Thesignature pad preferably stores captured signature data securely (in aread only format), such as locally in a file, database, etc. for furtherviewing of the signature, generate a graphic image file of thesignature, or transmit the signature data (e.g., as a character string)to a remote server for secure storage, creation of a graphic image file,or for viewing. The signature data may be captured as coordinate orpixel data, or coordinate or line data (e.g., beginning and end points,line length, and angle degrees, etc.).

By making the signature pad a stand-alone application, such as a Flashprogram, the signature may be captured on its own, without submitting anaccompanying HTML form or the like. The signature pad may be furtherconfigured to notify a site or server (e.g., a merchant web server) whenthe signature has been properly captured and optionally, whether thesignature is verified against a signature on file. Additionalinformation may be captured along with the signature.

FIG. 1 shows an exemplary embodiment of the present invention. Asignature block (signature pad/box) 102 can be displayed on a computerscreen, such as within a web browser window. The signature block 102 ispreferably generated by a Flash or MS Sparkle program and can be part ofa larger form object 100 that can include text, graphics or fields forother data entry.

The signature pad 102 may be displayed on the computer screen in anyshape (e.g., rectangle-shaped) and is configured to allow the computeruser to draw, for example, to sign their full name, nickname, orinitials. For aesthetic reasons, it may be preferable to include asignature block that is sized to match a corresponding form or web page.The signature pad 102 may appear, for example, on an Internet shoppingcart or web form. The preferred functions of the signature pad are Draw:to write the signature, Clear: to erase a signature (“Clear” button 104)and Submit or Validate: to send, submit, store or validate the signature(“Validate” button 106). In some embodiments, the signature pad 102 mayadditionally or alternatively define the background color of thedisplayed signature pad and/or the color of the raster (e.g., pen)and/or fill the displayed signature block with a predefined background.

The signature pad 102 may be configured to capture the coordinates inputfrom a peripheral device, such as a mouse or other pointing device. Thecapture process preferably outputs x and y coordinates of the locationof the windows cursor within the signature pad 102. The capturedcoordinates may then be used to create a graphical image of the rawsignature (i.e., biometrically accurate signature). The coordinates orthe graphical image file or both could be stored for later use.Preferably, the signature data is stored as line data, e.g., beginningand end points, line length and angle degrees. Stored signature data ispreferably secure and could be used to generate a graphic image file(gif) or other image file (e.g., .bmp, .jpg, tif, etc.), when completed.However, in some embodiments, the signature pad 102 may acquire thesignature data and/or graphical image of a raw signature using camera,such as, for example, a digital camera. In one non-limiting embodiment,the digital camera may be coupled to or integrated in a cell-phone ormobile device.

In some embodiments, the signature pad 102 may alternatively oradditionally capture dynamic characteristics of a signature, such as,for example, (i) the size and shape of the entire signature, (ii) thenumber of strokes in the signature, (iii) the order or sequence ofstrokes of the signature, (iv) the number of closed loops of thesignature, (v) the distance or length of strokes of the signature, (vi)tangents and derivatives of segments and/or points of the signature,(vii) the velocity or speed of segments and/or an entire signature, andderivatives thereof, and/or (viii) the pressure applied in making thestrokes of the signature (if a pressure-sensitive signature pad isemployed).

In some embodiments, the signature pad 102 may alternatively oradditionally capture the date and time (e.g., at millisecond intervals)that each point or pixel of a signature was captured. In onenon-limiting embodiment, the signature pad 102 may set the rate at whichthe timing of points or pixels are captured at a predetermined rate(e.g., within a range of 40-120 samples/second), and the rate may bedetermined by, for example, the processing speed and/or sampling rate ofthe client computer 408.

Preferably, signatures are displayed within signature pad 102 while theuser is entering the signature. For example, the signature pad 102 couldbe configured to use a computer mouse input to generate a signature.When the left mouse button (not shown) is depressed, and the windowscursor is within the signature pad 102, the coordinates of the mousecursor can be captured by signature pad 102 and simultaneously displayedtherein to the user via a program display function (e.g., Flash lineLINETO command), so that the user can see the signature as it is beingwritten. Captured signatures, signature data, graphical objects, etc.may be accessed by any means, such as online through a web page or link.In some embodiments, in addition to a handwritten signature captured bythe signature pad 102 as it is written, the captured signature mayalternatively be stored signatures previously captured by the signaturepad 102, imported/uploaded images of a handwritten signature, and/or acursive font typed into the displayed signature pad 102 or previouslycaptured.

Preferably, the graphical image of the biometric signature and/or theraw signature data is transmitted to a remote server for storing. Theimage or signature data is preferably stored in a file format and can beassigned an URL address for convenient access. As mentioned above, thesignature may be captured and stored independent of any otherapplication. Therefore, if the signature is captured in connection witha merchant web site or the like, the present invention may be configuredto notify the merchant when the signature has been submitted, if thereis an error, and even whether the signature is verified, such as againsta stored signature. For example, the signature pad 102 or remote server(see FIG. 4) may be configured to provide the URL of the storedsignature to the merchant or party requesting the signature data. Filesare preferably stored with advanced encryption methods for security.However, some embodiments may not store the received biometric signatureand/or raw signature data.

The signature coordinates or graphic image may be submitted and/orstored along with any additional accompanying data, which could be usedto identify the signature or signer. For example, as shown in FIG. 2, aform field to enter the Email Address could be included in a separateblock 202. Any data, including such client-side data, could be stored orcaptured with a signature. For example, one or more of the following: aClient ID, Customer ID, an IP address, a Session ID, an email address,and Company ID, SSN, EIN, SIN, etc. See also FIG. 7. This additionaldata may be supplied by the signer by typing the information into formfields (on the signature pad itself or in the hosting application, suchas the web browser HTML code), or it may be embedded in HTML or code ora client program used to host or display the signature pad 102. Ifrequired data is missing or invalid, the signature capture process couldbe configured to display an appropriate error message to the user in theform of a dialog box, web page, etc.

Another example is shown in FIG. 3. An HTML form 300 includes fields 302for entry of City, Location, Zip, Phone, 800#, and Fax number. Thedrawing pad 102 has a Submit button 304 below it. If the Submit button304 is depressed before all the fields are filled in or before thesignature is drawn, an error message could be generated. Alternatively,the signature can be submitted irrespective of whether all the HTML formfields 302 have been filled in and the HTML form can be submittedseparately.

Note that the signature pad can operate independent from an HTML page.Further, the present invention is not limited to integration with anHTML page and the functionality of the signature pad 102 can beintegrated with other programs, such as XML, XAML, MS Sparkle, MS .Net,etc.

When additional data is supplied, the data could be captured with thesignature or in a separate file which is later merged with thesignature. In the alternative or in addition thereto, it may be stored,for example in a database, to aid in future lookup of the capturedsignature. The signature and its accompanying data could be submittedindependently from the hosting application form. If it is submitted tothe server with the form, the server may redirect or download a web pageto the client. If it is submitted independently, the hosting applicationor the signature capture program may display a message, such as a dialogbox, to the user and/or redirect the user when the signature has beensuccessfully received by the server or if there is an error.

The signature or drawing can be captured on the client side, forexample, with program executed on the client PC, for example, by a webbrowser. The program could comprise written instructions in any computerprogramming language having the appropriate capabilities, but ispreferably designed specifically for online (e.g., Web) applications,such as HTML, XAML, Flash, JavaScript, MS Sparkle, MS .Net, MS Longhorn,Vista, etc. The program can be configured to record x and y coordinatesof the signature, which may be used for viewing, secure storage orediting, and/or send the signature data in the form of pixel data, orcoordinate or line data (e.g., begin and end points, line length, andangle degrees, etc.), to a server for viewing/editing/storage. An imagegeneration program or module may use the coordinates to create thesignature or drawing as a graphic image, which can be stored as a fileon a file system, possibly for access online or in a database.

One skilled in the art will understand that the signature capture andimage generation processes could be combined and implemented by a singlecomputer program or by several separate components residing together orremote from each other. For example, a Flash program could be downloaded(e.g., with or from an HTML page) to capture the signature data and sendthe data to a remotely located program, which generates the image of thesignature.

The signature may be submitted as part of a hosting program form ortransmitted transparently and independently from a hosting applicationfor, or uploaded to a server as coordinates, for example, in an ASCIIdelimited character string as x/y coordinates or as line data comprisingbegin and end points of each straight line or angle degree and linelength, or as a graphic image file. A server may use the coordinates tocreate a graphic image file, and may store the graphic image file orsignature data for future display or editing.

Once the signature has been recorded and submitted at the client side, a“Thank You” message could be delivered to the client. For example, theclient could be redirected to a web page, a “pop-up” or dialogue boxcould be displayed, etc. This message could be generated by server-sidescript or called from the client.

Signatures can be validated by comparing the generated signature orsignature data against a stored signature or stored signature data. Thestored signature or stored signature data could be identified by usingadditional data, such as email address or name, or a unique ID such as aclient ID or session ID, which could be embedded as a parameter in ahosting application form (e.g., HTML or XAML) that loads the signaturepad application or typed directly into the hosting application form orsignature pad form field(s) so that both the hosting application and thesignature pad application send the same ID to the server. This ID couldbe used by the merchant or other entity requesting the signature, toaccess the stored generated signature. In some embodiments, signaturevalidation may be achieved by additionally or alternatively generating achecksum of the generated signature or signature data, storing thechecksum, and using the stored checksum to validate the generatedsignature or signature data. Further, in some embodiments, signaturevalidation may be achieved by additionally or alternatively using aone-way hash, such as, for example, the MD4 Message-Digest Algorithm,the MD5 Message-Digest Algorithm, or Secure Hash Algorithm.

The client and/or the merchant could receive the Thank You via an emailgenerated by the signature pad or by a server script. Such an emailcould contain links(s) to and/or attachment(s), such as an HTML, PDF, orWORD document, containing information related to the signature, such asa graphical image of the signature, additional signature data, areceipt, the signed document, verification that the signature wasrecorded properly or matches a signature on file, etc.

FIG. 4 is a block diagram of a system for capturing online electronicsignatures according to an embodiment of the present invention.

As shown, the system 400 could include a web server 402 (e.g.,“merchant” server), a signature link server 404 coupled with a storagedevice 406, and a client interface 408, each coupled with or otherwisein communication with an electronic data network 410, such as theInternet.

The web server 402 may be configured to provide online content such asHTML pages, java programs, streaming broadcast data or multimediaservices, etc. Such content maybe accessed and displayed, played,executed, etc. by client 408, such as via a web browser such as INTERNETEXPLORER. In one non-limiting embodiment, the content may be enteredmanually (e.g., from a merchant located at the premises of the client408) instead of being received from a remote source. Within the contentto be displayed may be a call, such as an embedded object request, whichcauses the client 408 to access the signature link server 404 anddownload a program element configured to display a signature block, suchas described above with respect to FIGS. 1-3. Alternatively, in someembodiments, instead of being downloaded from the signature link server404, the program element may be pre-installed on the client computerinterface 408 (e.g., by a manufacturer of the client 408), installedlocally (e.g., from a storage medium at the premises of the client 408or connected to the client 408 over a local network), or downloaded fromthe web server 402. Further, in embodiments, where the program elementis not pre-installed on the client 408, the program mode may bedownloaded and/or installed just before execution or at any time before.That is, in some embodiments, download and/or installation of theprogram element may follow and/or be caused by access, display, and/orexecution of the content (e.g., via a link or command embedded in thecontent, which may be from the web server 402), but, this is notrequired. In other embodiments, the program element may be downloadedand/or installed before and/or independent of access, display, and/orexecution of the content. In some embodiments, downloaded orpre-installed versions of the signature program may be a plugin ornative application.

The client 408 executes the program, such as within a web browser, andthe user may enter a signature, such as via a peripheral device, such asa computer mouse. The client displays and captures the biometricsignature of the user as described above. The signature data may bestored locally or transmitted directly to the signature link server 404,which can be configured to generate a graphical image of the signature.Otherwise, a graphical image of the signature could be generated locallyand transmitted to the signature link server 404.

The signature link server 404 can store signature data (e.g.,coordinate, pixel or line data) or signature images in a storage device406, which may be part of the server or a separate data storage device.However, in some embodiments, storage of the signature data may beoptional. As described above, additional data can be stored with thesignature image (e.g., in the image itself, in a text file on the filesystem, etc.) or in a database. For example, additional form data may betransmitted to the signature link server 404 along with the signaturedata and/or a graphical image. The additional form data could be storedin the storage device 406, such as in a database, and linked to thegraphical image of the signature or to the signature data.

Preferably, the signature data and/or image files can be made accessiblevia the electronic data network 410. Alternatively, signature data,additional data, and/or graphical images could be transmitted directlyto the web server 402 from the client 408. In some embodiments, storageof the signature data and/or image files received by the signature linkserver 404 is optional. In one non-limiting embodiment, signature dataand/or an image file received by the signature link server 404 are notstored at the signature link server 404. For example, the signature linkserver 404 may save nothing or just save a receipt of the transactionand/or transmit the signature data and/or image file to the web server402.

The generated image can be a signature only, or may include otherelements, such as text element related to contract terms or otherinformation associated with an online transaction. For example, as shownin FIG. 5, several clauses are combined with the signature to form anonline electronic signed contract.

After the signature and optional data is received by the server, theserver may save and/or display the receipt of the transaction or theagreement text for which the signature was required. For instance, whenmaking a purchase online, the resulting “Thank You” page may DISPLAY thedetails of your order along with the signature image embedded in theHTML as a signed receipt for the customer to print for future reference.This data may be optionally re-displayed with a dynamic webpage thatgathers the data from storage and displays it preferably as HTML alongwith the embedded signature image. This data could optionally be storedas a static HTML webpage on the server for future reference, especiallyfor the merchant to print off in case of a credit card chargebackdispute.

As another example, when submitting a signature in order to agree to anagreement or Terms & Conditions, the next page could display theagreement or Terms & Conditions with the signature image embedded at thebottom of the webpage. In other words, the FIG. 5 “Thank You” page couldstore the agreed-upon text and/or accompanied data within the signaturegraphic image file itself or as text on the webpage along with thesignature graphic image file.

Since the signature capturing process is independent, it may benecessary to interact with a corresponding process. For example,consider the case where an online merchant desires that a signature berecorded in connection with online purchases made from its website. Inthis case, client 408 downloads an HTML page from merchant server 402 inorder to purchase merchandise online. At some point in the purchaseprocess, a signature will be required. The merchant HTML page can callthe signature program, which can be downloaded from the signature server404 and then executed in a web browser of client 408. As noted above, insome embodiments, instead of being downloaded from the signature server404, the signature program may be pre-installed on the client 408,installed locally, or downloaded from the merchant server 402. Forexample, when payment information is being entered, before submission ofthe information, the signature may be recorded. Accordingly, client 408displays and captures the biometric signature of the user as describedabove. The signature data may be stored locally or transmitted directlyto the signature link server 404, which can be configured to generate agraphical image of the signature. Otherwise, a graphical image of thesignature could be generated locally and transmitted to the signaturelink server 404.

Now, before the payment information is submitted to the merchant orthird party system to consummate an online transaction, it may bedesired that the signature be confirmed or even validated. In this case,the merchant HTML page can be prevented from being submitted until thesignature is confirmed or validated by the signature server 404. Forexample, a required browser cookie or hidden field in an HTML page mightonly be populated when the “Thank You” message is generated by signatureserver 404. This way, no online transaction can occur without aconfirmed biometric signature being recorded. The hosting applicationform with the required field or browser cookie may optionally besubmitted to the server 402 (e.g., a merchant web server), which checksto make sure that the required fields have been set or filled, and mayoptionally display an error message or the received data and/orsignature as a receipt. The signature may be displayed in the “ThankYou” page as an embedded HTML IMG tag linked to the URL of thesignature, which may reside on signature server 104 or be retrieved tothe server 402. The value of the required field or the unique ID may beused in the image URL/file naming convention, so the server 402 knowsthe URL to the signature image file.

In order for the signature image to be retrieved securely from theserver 404, either by the client 408 or server 402, the receiving partymay be authenticated. Such authentication could include, but is notlimited to, (1) checking to see if the retrieval request is from someonelogged in to the server 404 with the appropriate account; (2) checkingto see if the retrieval request is from the same IP address as theoriginal signer within a limited period of time; (3) checking to see ifthe retrieval request is from a previously designated IP address, suchas of a merchant, as configured by the server 404; or (4) checking tosee if the retrieval request is from someone using the same session orbrowser cookie as the original signer within a limited period. HTTPSand/or SSL secure certificates, or the like, may be used whentransmitting data between computers. The servers 404 and 402 may be thesame server in some embodiments. Further, when the signature or datafile are stored, they can be stored encrypted by standard encryptiontechniques. When, the signature or file is retrieved, standarddecryption techniques can be used to decrypt the signature or filebefore it is sent to the retriever.

FIG. 6 is a flowchart of a method for capturing an online electronicsignature. The method may be implemented with systems and programs asdescribed above with reference to FIGS. 1-5.

At step S6-1, when a user accesses a program, web page, etc. which isconfigured to use an online signature according to an embodiment of thepresent invention, a signature display block or drawing pad is displayedon the user computer separate from or in connection with thecorresponding program, web page, etc. The signature display block ordrawing pad is preferably configured to perform at least the signaturecapture and display process.

At S6-2 the user signs in the drawing via a computer peripheral device,such as a mouse. If the drawing is acceptable to the user, he or she maysubmit the drawing via a submit function or button (S6-3). At S6-4,stored captured data is sent to a server for storing and/or generationof the graphical signature. As described above, additional informationmay be submitted with the coordinate data or with the signature imageand therefore, the signature capture process may be coordinated withother data entry.

A clear function or button can also be provided. If at step S6-3 theclear function is executed, coordinate data is erased and processingreturns to step S6-1.

Data may also be sent directly to a server application upon submission(S6-5). A server application can store the signature coordinate data orgenerate an appropriate graphical image of the signature for displayand/or storage, which may also include other items such as text or data(S6-6). The accompanied data may be stored separately from the graphicimage file, such as in a database and/or in a text file and/or in astatic HTML “receipt” webpage of the transaction.

If there is a problem (S6-7) with the signature or data related thereto,an error message can be displayed (S6-8) and processing can be returnedto step S6-1. Data may be erased or left in place for correction.Otherwise, a final step can be performed (S6-9), such as redirecting theuser to another web page, program, etc. (S6-10) or displaying a successmessage indicating that the transaction is complete and/or the signaturehas been successfully captured and generated (S6-11). However, in someembodiments, the signature program may not update the client (e.g., byperforming step S6-9 or S6-10) in the case of successful signaturecapture and storage.

According to another embodiment of the present invention, the signaturecapture program could be included within a hosting application asstandard functionality or as a plug-in. Web pages could invoke thesignature capture feature of the hosting application through standard orbrowser-specific HTML or XML.

FIG. 8 is a block diagram of a system for capturing both a client-sidesignature and client-side data according to aspects of the presentinvention. System 800 may include a number of servers that are coupledwith an electronic data network, such as the Internet and world wideweb, for communicating content, data, software program code and modules,etc. for the purpose of recording an online transaction. Client sideprograms may include a signature pad 802, which can be implemented asalready described herein. One or more web pages may be implemented forthe purpose of receiving customer information associated with thetransaction. For example, payment information can be received through aform or HTML page 804. An order confirmation form 806 is also utilizedwith the online transaction. The modules or forms 802-806 cancommunicate with a server 808, which is coupled with one or moreadditional servers that perform features according to embodiments of thepresent invention, such as, for example, record receipt generationand/or storage, fraud protection data storage and/or services 812, etc.Online commerce can be transacted through system 800 as alreadydescribed above and as further described below.

In some embodiments, signature pad 102 and/or signature link server 404may normalize the captured signature data so as to be relativelyconsistent irrespective of the hardware utilized in its capture.Different devices will capture signature data differently (e.g., atdifferent densities and rates depending, for example, on resolutionand/or size of the signing surface, processor operating speed, mouseand/or signature pad sampling rate, the available RAM memory and thelike), and normalization reduces the effects of differences in thecaptured signature data.

FIG. 9 illustrates steps of a method for capturing client-side dataaccording to aspects of the present invention. The method starts at stepS-902 and proceeds to step S-904. A user (customer) navigates to a webpage, such as with a browser, that contains a screen scrape module orprogram code according to embodiments of the present invention. At stepS-906, the customer then enters form data onto the web page. As alreadydescribed herein, the form data may include information about thetransaction, payment information, information about the customer, etc.At step S-908, a copy of the HTML source code for the current web pageis obtained and its HTML DOM tree is iteratively walked by the screenscape program. For example, a custom java script using jQuery could bewritten to walk the DOM.

At step S-910, during the iterative walking process, each of the inputfields in the HTML can be replaced with identical fields containing theactual data that the user entered into the form. The HTML sourceincluding the client side data can then be transmitted to a remoteserver side program which, at S-912, can render the HTML including theclient side data as a file having a more appropriate file format forpermanent record keeping. For example, as described below, a program canbe provided that will render HTML into a pdf format. Processing ends atstep S-914.

In a typical configuration, the signature pad is integrated intoclient-side enterprise platform or shopping cart. When performing anonline transaction, a customer signs the signature pad, then clicks asubmit or proceed button. The signature pad can be configured tocommunicate with the server 808, which communicates with the client-sidescreen scrape program that performs the DOM scan. The scanned HTML codeis captured (e.g., by the server 808) and converted to an un-editablerecord including the actual data that was present on the client-sidemachine at the exact time of the transaction acceptance and execution.Other data such as terms and condition, geo location, device ID, etc.can also be captured and combined with the captured html data to createa permanent, un-editable record of the critical aspects of theelectronic transaction. This record could include the signature so as toappear as a signed contract. The permanent record can be subsequentlystored at a secure location, where it can be made available for view andretrieval for the purposes of transaction verification. Accordingly, anindelible image of what the customer sees when they enter thetransaction is captured.

FIGS. 10A and 10B illustrate primary CNPS calls and returns according toaspects of the present invention. FIGS. 10A and 10B illustrate logicaland data process flow according to aspects of the present invention. Asillustrated, during the check-out process, credit card capture can beinitiated which includes capture and verification of an online signaturethrough a signature pad as described herein, subsequently followed by anhtml capture performed by a screen scape program as described herein.The online order processing can be performed and if payment is rejected,the checkout process can be restarted at the credit card capture point.If the order is not rejected, then the permanent record can be generatedas described herein and securely stored. Further, a receipt page can betransmitted to the client containing the transaction information andoptionally pdf copy of the signed receipt.

FIGS. 11A and 11B illustrate processing data flows for generating andstoring a permanent record according to aspects of the presentinvention.

The PDF Rending process is preferably a standalone component within theCNPS process. The PDF Rending process can be made up of threecomponents: a generate PDF web service, a queue, and a PDF render job.As shown in the example of FIGS. 11A and 11B, the process can be startedby a client calling the generate PDF web service; the data can bevalidated, and the transaction inserted into the queue for processing(PDF generation). The queue is preferably first-in first-out (FIFO) andwill hold the transactions.

The PDF render job can be a recurring, scheduled process that picks uppending transactions from the queue to create the PDF. The Render PDFjob may use the data from the web service call (now in the queue and DB)along with client specific settings within the DB to create the finalPDF. As shown, the job goes through a series of steps, includingupdating the transaction status in DB at each completion point, togenerate the final PDF. Once completed the final encrypted PDF is sentto the Receipt Server; once there the PDF is now accessible to theclient for view or download. The PDF as generated can be read only, password protected or otherwise generated to protect the content thereof.

FIGS. 12A and 12B illustrate processing data flows for generating andstoring a permanent record according to aspects of the presentinvention. The CNPS Server Design and process is preferably architectedto be a redundant, high available system with the capability to easy addservers and bandwidth to support increasing demand levels. An exemplaryCNPS process starts off with a consumer in the checkout process on amerchant's web site. During the checkout process the consumer shall bepresented with all the normal, industry standard checkout prompts. TheCNPS process can add a few extra components to the check process:signature pad, transaction profiling, Terms and conditions, screenscrape, and PDF rending of the receipt page.

As shown, communications are between the end user's browser and the CNPSsystem (client side) and between the merchant's server and the CNPSsystem (server side). The combination of both client and server sideinteractions can be used to profile the transaction (end user's device,IP, and checkout data) for a fraud score, capture the end user'ssignature, and scrape the order confirmation page. An outcome of all thedata and flows is the generation of a PDF that is an exact copy of theorder confirmation, the user's signature, the terms and conditions, andoverall fraud score.

The CNPS system can be constructed up of six main design areas thatinteract with each other, the end user, and the merchant to support theCNPS Process: CNPS web services; CNPS Admin web site; CNPS Database;CNPS client side libraries (runs on the user's browser); Signature Pad;Fraud Screening and transaction profiling.

Accordingly, according to aspects of the present invention, a novel DOMtraversal method of capturing client side html and data as it is enteredon the screen is provided. This method is universally applicable to anynumber of contemplated applications. However, according to aspects ofthe present invention, it is particularly applicable to capturingclient-side real-time data along with or in connection with anelectronic transaction. From this captured data a permanent record canbe created which can be combined with other information to create areceipt and permanent record of the electronic transaction. Thepermanent record can include a biometric online signature. The data andthe permanent record can be stored in a remote location for subsequentreview and retrieval. A skilled person will readily understand thataspects of the present invention can be used individually or combinedwith other aspects to fulfill the requirements of a particularapplication.

Thus, a number of preferred embodiments have been fully described abovewith reference to the drawing figures. Although the invention has beendescribed based upon these preferred embodiments, it would be apparentto those of skill in the art that certain modifications, variations, andalternative constructions could be made to the described embodimentswithin the spirit and scope of the invention.

1. A system for generating a record of an online transaction, saidsystem comprising: a computer interface module that records a user on apoint of sale terminal and outputs the recorded data; a user biometricgeneration module that receives said recorded data and generatesbiometric user based upon said recorded data; a screen scrape moduleconfigured to create an electronic file containing informationcorresponding to the display information on the computer screen and totransmit said electronic file to a remote server, said server beingconfigured to generate an un-editable computer file containing theinformation corresponding to said display information; a web page thatcontains a screen scrape module; a peripheral device selected from thegroup consisting of a mouse, a writing pad, keyboard arrows, and a touchpad; wherein said peripheral device captures a raw biometric data bygenerating a user biometric data file; and wherein said raw biometricdata is stored as line data, comprising beginning points, and endpoints, line length and angle degrees.
 2. The system as recited in claim1, wherein said electronic file is HTML and data obtained from thescreen scrape module that walks a Document Object Model DOM of an HTMLpage using a custom java script jQuery to insert data that has beeninput by a user into the HTML.
 3. A system for generating a permanentrecord including: means for extracting all content and data from awebpage, said data including data input into said webpage by a user ofsaid webpage; means for recording a user's biometric information togenerate biometric user information; and means for generating apermanent computer file record containing said content and data and saidsignature, said permanent computer file record including an image ofsaid content with said data inserted therein.
 4. The system as recitedin claim 3, wherein said webpage is HTML and said permanent computerfile record is a PDF.
 5. A computer implemented method for capturing anonline electronic transaction, said method comprising steps of: inconnection with an online electronic transaction, at a client computerinterface configured to display content or said online electronictransaction, executing a user biometric program configured to display auser data input block on said client computer interface, to receive rawbiometric signature data input from said client computer interface, andto capture biometric data and associate said biometric data with saidonline electronic transaction; electronically transmitting said capturedbiometric data in association with said online electronic transaction toa storage facility; after said biometric data in association with saidonline electronic transaction is received at said storage facility,electronically transmitting to said client computer interface and to aparty associated with said online electronic transaction a notificationindicating that the said biometric data has been received; and whereinsaid raw biometric data is stored as line data, comprising beginningpoints, end points, line length and angle degrees.
 6. The method asrecited in claim 5, wherein said biometric program is identified by alink in said content for said online electronic transaction.
 7. Themethod as recited in claim 5, wherein said biometric program ispreinstalled on said client computer interface.
 8. The method as recitedin claim 5, wherein said biometric program is downloaded to said clientcomputer interface independent of said content for said onlineelectronic transaction.
 9. The method as received in claim 5, whereinsaid content for said online electronic transaction is received from aweb server application associated with a first party and said storagefacility is associated with a second party separate from said firstparty.
 10. The method as recited in claim 5, further comprising a stepof generating an electronic representation of the signature from saiddata.
 11. The method as recited in claim 10, wherein said electronicrepresentation of the users personal biometric data.
 12. The method asrecited in claim 5, wherein said biometric program is executed with aplug-in.
 13. The method as recited in claim 5, wherein said content isweb content.
 14. The method as recited in claim 5, wherein saidbiometric data is HTML and data.
 15. A method as recited in claim 5,further comprising the steps of: extracting all content and data from awebpage, said data including data input into said webpage by a user ofsaid webpage; and means for generating a permanent computer file recordcontaining said content and data, said permanent computer file recordincluding an image of said content with said data inserted therein. 16.The method as recited in claim 15, wherein said webpage is HTML and saidpermanent computer file record is a PDF.